The modern transport network space is characterised by a large number of heterogenous networks which are interconnected by gateway servers. Each network may implement any one or more of a variety of transport protocols (e.g. Ethernet, ATM, TCP/IP; SONET/SDH). Where interconnected networks employ different transport protocols, adaptation services provided by the gateway servers facilitate transport of client data between the involved networks. In response to the demand for seamless communications across this “network of networks”, much effort has been made to develop generic connection management schemes that can be utilized by network service providers independently of the transport technology used. This work has resulted in the International Telecommunications Union (ITU) standard Recommendation G.805, which defines a layered functional architecture for transport networks. Based on the G.805 layer architecture two models have been developed: G.8080 for the control plane (Automatically Switched Optical Network—ASON); and Tele-Management Forum (TMF) model TMF608 for the management plane. TMF814 is an interface specification of TMF that instantiates the TMF608 model. G.8080 defines two types of call controllers: calling/called party call controllers (CCCs); and network call controllers (NCCs). Calling/called party call controllers initiate and terminate calls, whereas network call controllers interact with the CCCs and with connection controllers to manage connections within the network. Within the management plane, TMF814 provides an interface that uses the G.805 model of connections. The relationship between connections at different layers is known in the TMF814 interface. Thus it can be used to manage multi-layer connections across the network.
G.8080 uses the existing definition of a logical separation between calls and connections. A “call” may be understood as an “agreement” or an “intent” to communicate. Typically, the call will be represented by a call object which contains metadata concerning the call. Such metadata may, for example, include billing information; characteristic information (CI) of the call (e.g., transport protocol, bit rate, etc.); security parameters; and quality of service (QoS) requirements. While a call represents an agreement to communicate, a “connection” provides the actual means for communication. Thus, for example, instantiation of a call object indicates a client's intent to communicate, and provides the information required by network service providers to facilitate and manage the communications. On the basis of the call object, the network service provider(s) can then provide (usually through signalling protocols) the physical network resources (that is, the connections) required to transport the client traffic.
FIG. 1 illustrates a possible scenario in which it is desired to transport Ethernet frames (MAC frames) between an originating client 2 and a destination client 4 using the conventional G.805 architecture. In the example of FIG. 1, the two clients are located in separate networks, so that it is not possible to transport MAC frames “directly” between the two nodes. Instead, an originating Client Call Controller (CCC) 6 resident in the “originating” client 2 establishes a MAC call segment 8 and an associated connection 10 with a corresponding MAC Network Call Controller (NCCMAC) 12 in an ingress Network Element (NE-1) 14 of a broadband (in this case, a SONET/SDH) network 16. This MAC call/connection enables MAC frames to be transported between the originating client 2 and the ingress Network Element (NE-1) 14. The ingress NCCMAC 12 then sets up a second MAC call segment 18 with an associated NCCMAC 20 in an egress Network Element (NE-2) 22 of the broadband network 16. However, because the broadband network 16 cannot transport MAC frames, an associated MAC connection cannot be established between the ingress and egress NEs 14 and 22. However, a VC-3 connection can be established, and, with appropriate adaptation, can support the bandwidth requirements of the flow of MAC frames. Accordingly, the network service provider establishes a VC-3 call segment 24 and an associated VC-3 connection 26 between VC-3 network call controllers (NCCVC-3) 28 and 30 in the ingress and egress NEs 14, 22. Adaptation services 32 are then provided in the ingress and egress network element 14, 22, so that a MAC connection can be “presented” to the ingress and egress NCCMACs 12, 20 and thereby facilitate transport of MAC frames across the broadband network 16. Finally, the NCCMAC 20 in the egress network element 22 establishes a MAC call segment 34 and an associated MAC connection 36 with a corresponding Client Call Controller 38 in the destination client node 4.
In the example of FIG. 1, the lack of transport network resources capable of supporting a MAC connection between the ingress and egress NEs 14, 22 is overcome by providing a VC-3 connection 26 and adaptation services 32 to effectively emulate the required MAC connection. ITU standard G.805 enables this connection emulation scheme to be applied recursively across virtually any number of network layers. By this means, traffic flows across virtually any arbitrary mixture of heterogenous networks can be supported. A further advantage of ITU standard G.805 is that the recursive layering scheme can be extended to include new transport protocols and technologies as they become available.
However, a limitation of G.8080 (that is, the Automatically Switched Optical Network—ASON) is that it is defined for a single-layered control plane. Thus, in the example of FIG. 1, overall control of communications between the originating and destination client nodes is provided by MAC call segments between each of the involved MAC Call Controllers. Between each CCC and its respective NCCMAC, the MAC call segments 8, 34 are associated with MAC connections 10 and 36, and thus also have awareness and control of those MAC connections. However, between the ingress and egress Network elements 14 and 22, the required MAC connection is emulated using a VC-3 call/connection 24, 26. The “parallel” MAC call segment 18 between the NCCs 12, 20 “sees” a MAC connection, and has no awareness of either the underlying VC-3 call 24 or its associated VC-3 connection 26. The VC-3 call 24, on the other hand, “sees” an STS traffic flow, and has no awareness that it is actually transporting encapsulated MAC frames. This situation creates a number of difficulties.
In particular, when an NCC determines that there are no (or insufficient) resources in its own layer, it responds by merely indicating that the connection attempt has failed. It cannot automatically determine whether or not adequate resources exist in another layer. Even if such server-layer resources are present, the NCC has no means of instantiating the required connection or the necessary adaptation services. This situation is usually remedied by manual configuration of server layer trails that are then used by client connections. It is an operational procedure to the network operator. Thus, following the above example, the VC-3 call segment 24 and connection 26 must be manually provisioned by the network service provider, and presented to each NCCMAC 12 and 20 as a MAC trail. Once this has been done, the MAC call segment 18 can direct a connection controller to instantiate a MAC connection for it. This requirement for manual provisioning of server-layer connections effectively precludes automated instantiation of connections across heterogenous networks. Furthermore, network service providers in each network require a very high level of understanding of subscriber traffic requirements in order to properly provision network resources. Furthermore, a network failure in a server layer cannot be readily correlated with client-layer calls, because the server-layer call has no awareness of the client-layer calls that it is actually supporting.
An efficient technique for overcoming these limitations is highly desirable.